This invention relates to managing state data, and more particularly, to a method and apparatus which uses an enhanced scan cell to swap state data in an electronic or other computational system, primarily for multi-tasking purposes.
In an electronic system, or other computational system, it is sometimes advantageous for cost, size, or other reasons to simultaneously process multiple tasks. As used herein, the term xe2x80x9ctaskxe2x80x9d refers to the collection of operations, or pieces, necessary to complete a particular process (e.g., decoding an incoming facsimile image). The terms xe2x80x9celectronic systemxe2x80x9d or xe2x80x9ccomputational systemxe2x80x9d or xe2x80x9csystem,xe2x80x9d as used herein, covers a wide variety of devices that are recognized by those skilled in the art including, but not limited to, integrated circuit (ICs), hybrids, and multi-chip modules (MCMs). The term also includes printed circuit boards (PCBs), subsystems, and combinations of PCBs and/or subsystems.
The appearance of executing more than one task at the same time in a single system is known as xe2x80x9cmulti-tasking.xe2x80x9d Multi-tasking is accomplished by dividing two or more tasks into smaller, manageable pieces, and then, interspersing the processing of the pieces. By quickly switching from the pieces of one task (e.g., when it is made inactive or suspended) to the pieces of another task (e.g., when it is made active, initiated, or resumed), an appearance of simultaneous task execution is created.
The ultimate goal of multi-tasking is to fully utilize the capabilities of a system by preventing long periods of idle time where no useful processing is occurring due to a lack of data, and/or commands, or user input. An additional reason for multi-tasking is the fact that a minimal hardware implementation of an algorithm may provide far more processing bandwidth than a single task requires. Without multi-tasking, this bandwidth is wasted and the hardware is under-utilized. For example, without multi-tasking, a system that requires the appearance of simultaneously executing two tasks would require two processors, even though a single processor could be built to have enough bandwidth to process both tasks in the necessary time. In some cases, the processor needed would be the minimal implementation and require no modification and in other cases, the processor would require some speed improvements but would still be substantially smaller and cheaper than having two smaller processors.
For maximum efficiency, a system must have the ability to switch tasks at any time; this is known as a xe2x80x9cpreemptive multi-tasking.xe2x80x9d For example, consider an image processing device (IPD) working on a first task, such as decoding an incoming facsimile image. In an ideal system, the IPD decodes the incoming image until an information transfer is requiredxe2x80x94i.e., once the IPD decodes all of the information that is currently available for that incoming image. Then, right-away, the IPD switches to working on a second task, perhaps processing a scanned-in image, while the information transfer takes place. After receiving more information for the first task, the IPD then immediately switches back to working on the first task where it left off. The IPD continues to switch between the two tasks whenever an information transfer is required until both tasks are completed. Thus, a preemptive, or unrestrained, multi-tasking system makes better use of its processing devices by immediately switching between tasks according to the availability of information.
Often, however, task switching requires the storage of the context (i.e., the state data) of a system, or of a functional block therein (e.g., a partition of logic internal to an IC), at the end of processing a piece of one task; and the retrieval of context information at the beginning of processing a piece of a resumed task. This introduces a bottleneck for multi-tasking systems because of the time and overhead required to manage state information (i.e., saving/restoring state data) for the individual pieces of multiple tasks. Furthermore, this problem is exasperated in complex systems that have unexposed functional blocks, such as logic buried in an IC, because of the limited access to the internal state data therein. For example, the PM-22 IC from Pixel Magic, Inc., contains an input pipeline, a JBIG pre-processing pipeline, and a JBIG decoder pipeline, wherein the first two pipelines affect the state data for the JBIG decoder pipeline. Although some of the state date in these pipelines can be read when saving the state of a piece of a task, much of the internal logic for the JBIG decoder pipeline is not exposed (e.g., it is buried within the IC), and thus, during multi-tasking the state data therein is not directly accessible.
A prior art solution for restoring the appropriate state data for a resumed task is to replay the previously saved input data to the JBIG decoder pipeline (i.e., the unexposed functional block), and then, wait for the decoder to regenerate the missing state data. Adding to the difficulty of this procedure is the fact that, when resuming a task, the state data in the input and pre-processing pipelines usually is not the input byte sequence needed to regenerate the state data in the JBIG decoder pipeline. Thus, to regenerate the correct state data to resume a task, all of the pipelines need to first be primed, which requires numerous, time-consuming calculations.
To coordinate these complex calculations, one prior art solution restrains task switching to specific xe2x80x9cboundaries,xe2x80x9d and thus, does not allow preemptive multi-tasking. For example, an application employing the PM-22 IC to process images, programs the IC to stop processing an image at the end of a predetermined line, or a xe2x80x9cline boundary,xe2x80x9d as if it was the end of the image. Next, the application prompts the IC to save the accessible state data, and then, to switch to a different image for processing.
In operation, the IC processes a first piece of a first task, such as decoding a first image up until a particular line boundary for the first image. Then, the IC saves the resulting, accessible state data at the end of the first piece of the first task. Next, the IC begins to process a first piece of a second task, such as decoding a second image up until a predetermined line boundary for the second image. Again, the IC saves the resulting, accessible state data at the end of the first piece of the second task.
To switch back to the first task and resume decoding the first image, the application must prompt the IC to restart its decoder at the line boundary where it stopped decoding the first image. In order to do this, however, the application must first restore the previously saved state dataxe2x80x94i.e., the accessible state data that resulted after the first piece of the first task was processedxe2x80x94to the IC""s decoder. Then, the application must wait for the decoder to regenerate the appropriate state data by processing the previously saved state data that was accessible at the time the first task was suspended.
Requiring task switching to occur on line boundaries is annoying from a multitasking standpoint because it does not allow the application to task switch in reaction to an event. Moreover, requiring tasks to switch on specific boundaries does not fully utilize the capabilities of a system. Furthermore, system memory is reduced and/or additional hardware (e.g., registers), system control, and CPU intervention (e.g., from a coupled host) is required for storing/restoring state data for the pieces of the multiple tasks. Thus, it is highly desirable to expose more of. a system""s functional blocks, or modules, so that state data can be managed more efficiently during multi-tasking.
During the manufacturing process of a system, the exposure and accessibility of state data is also of interest for testing and debugging. This is especially true with regard to today""s complex ICs, many of which have multi-tasking capabilities. Often, the clues to system problems are found in the states of functional blocks within an IC. This requires the determination of the proper operation of an IC""s internal logic, such as each internal cell (e.g., a flip-flop). The ability to control the states of these cells helps debug other parts of the system by setting up a known condition for input to the functional block of interest.
To improve the exposure of the functional blocks of a system, many designers follow the IEEE specification 1149.1, also referred to as the JTAG specification. This commonly used specification sets out a standard for a scan chain logic architecture which enables verification of dense, complex systems while minimizing the number of external test pins.
Scan chain logic provides access to the cells of an entire IC, or a functional block therein, via a single, Scan_Input input pin at one end, and a single, Scan_Output output pin at the other end. By connecting the output of one scan cell (e.g., a flip-flop) to the input of another, a chain is created through a functional block therein. The chain may be employed for testing via control pin(s) which are connected to each scan cell.
By asserting the control pin(s), state data can be loaded into the scan cells, unloaded from the scan cells, and/or serially shifted around the chain, from the Scan_Input pin to the Scan_Output pin. Such state data manipulation allows for the monitoring of a system to detect and pinpoint design and manufacturing defects. Furthermore, since the JTAG specification is a widely followed standard, it is easy to implement a scan chain logic architecture into a design.
In fact, today a scan chain logic architecture can be automatically integrated into a system using electronic design automation (EDA) tools, computer aided design (CAD) tools, computer aided engineering (CAE) tools, and data formats such as the Boundary-Scan Description Language. These tools automate the creation of a scan chain logic architecture into a design in accordance with user-specified design constraints (e.g., requirements for fan-out, fan-in, set-up time, hold time, and other design parameters). Additionally, these tools efficiently connect and route the scan cells (e.g., flip-flops) of a scan chain logic architecture.
Because both multi-tasking and scan chain logic are common in today""s systems, it would be beneficial and efficient for cost, design time, and functionality purposes to implement and enhance multi-tasking by managing state data with an enhanced scan chain logic architecture.
The present invention proposes use of enhanced scan chain logic in a processor to improve multitasking and testability. A major portion of the state of a processing module is composed of the states of all the flip-flops in the module. By implementing each state flip-flop as a scan cell containing an active flip-flop and a scan flip-flop, task state switching can be accomplished in a single clock cycle by swapping the contents of the two flip-flops. After one state swap and before the next, the state information from the task that was suspended by the last swap is shifted out of the scan flip-flops as the state information for the next task to run is shifted in. The use of scan logic also greatly improves testability of the module.
To further simplify and clean up the multitasking process, the functional blocks of a device may be made distinct to allow only specific blocks to be saved and restored. Mechanisms can be provided to allow state information to be saved and restored to either an attached local SRAM or, through a DMA interface, to main system memory. State data may also be saved by allowing the control application to read the state data through a register interface.
In an integrated circuit containing multiple processing modules, to minimize the amount of state data being manipulated, saving and restoring state is controllable on a module by module basis through the multitasking register. The inventive design eliminates the need to save and restore the state of modules that are not being used. This is particularly useful because the operation of some modules is mutually exclusive.
In the present invention, at the chip or integrated circuit level, the modules are connected into a chain to allow data to be shifted into the chip serially through the first module in the chain and to allow data to be shifted out of the chip serially through the last module in the chain. The ability to selectively save and restore module state data on a module by module basis is implemented by logic in each module that discards, without outputting, the module""s state if it is not being saved and routes data being shifted into the module around the module""s scan chain if the module is not being restored.
Saving and restoring state in each module is accomplished through enhanced scan chain logic. Each module is implemented with special flip flops that actually contain scan chain logic. The chains in each module are kept distinct to allow individual modules to be saved and restored. Each module""s chain is extended to a multiple of 16 bits in length to make the bit alignment of data within words independent of the collection of modules being saved.
Each enhanced scan flip flop is composed of an active flip flop, a scan flip flop, and some multiplexing logic for control. In addition to the normal Data_ln, Clock and Data_Out connections of a normal flip flop, the scan cell also has a Scan_lnput, a Scan_Output, and two scan control signals, Shift and Swap.
When the Swap control signal is high on the rising edge of clock, the data in the active flip flop is exchanged with the data in the scan flip flop. This exchange is used to swap the current state of the active flip flop with the state to be restored which should be in the scan flip flop. When the Swap control signal is low, the active flip flop behaves as a normal positive edge triggered flip flop and the function of the scan flip flop is governed by the Shift control signal. When the Shift signal is high during the rising edge of Clock, the data on Scan_Input is shifted into the scan flip flop. When the Shift signal is low, the state of the scan flip flop does not change. With the exception of the first and last scan cells in each module""s chain, the Scan_Output of each scan cell in a module is connected to the Scan lnput of another flip flop in the same module. The Clock signals of all scan cells are connected to the chip""s clock distribution tree.
The module level control logic deals with the scan chain through only a few signals. All data being fed to a module""s scan chain is loaded in through the Scan_ln input which is connected to the Scan_lnput of the first scan cell in the module""s chain through the module level control logic. All the data in the module""s scan chain is read out through its Scan_out output which is internally connected to the Scan_Output of the last scan cell in the chain through the module level control logic. The Swap control signals of all the module""s cells are connected in parallel, as are all the Shift signals in the module. The management of scan data at the module level is accomplished through a standardized module control logic interface consisting of the following signals: Scan_In, Scan_In_Enable, Scan_In_Ready, Scan_Out, Scan_Out_Enable, Scan_Out_Ready, Swap, Enable, Reset_Count, Save, and Restore.
Each module enable can be controlled independently through bits in the Master Enable Register. The state of each module""s Save and Restore signals can be controlled independently through the Multi-tasking Control Register. Through the Multi-tasking Control Logic the application can generate appropriately timed pulses for the Swap and Reset_Count signals of all modules.
Scan_In is a module input that is connected to the Scan_lnput signal of the first scan cell in the module""s chain of scan cells. This input is connected to the Scan_Out of the previous module if one exists or to the Chip""s source of scan data otherwise.
Scan_In_Enable is an input that indicates to the module when valid data can be shifted into the module. Data is considered to be shifted into the module whenever there is a rising edge of the core clock, this signal is asserted, and the module is asserting Scan_In_Ready. Scan_In_Enable is connected to the Scan_Out_Ready of the previous module if it exists. Otherwise, it is connected to a signal in the Chip""s scan logic that indicates the availability of scan data.
Scan_In_Ready is a module output that indicates that the module is now ready to take input data. This signal is asserted when the module is in the process of discarding its own state. A module discards its own state when Save is not asserted and Restore is. Asserting Scan_In_Ready in this situation allows the data to be restored to shift be shifted into the module. While the module is not discarding its state data Scan_In_Ready is logically connected to the module""s Scan_Out_Enable signal. The Scan_In_Ready signal of each module is connected to the Scan_Out_Enable of the previous module if it exists. Otherwise, it is connected to the logic that loads the scan data.
Scan_Out is a module output that is logically connected to Scan_Output of the last scan cell in the module""s chain of scan cells if Restore is asserted or to the module""s Scan_In input if Restore is not asserted. This signal is connected to the Scan_In of the next module in the module chain if one exists or to the logic that saves the state information otherwise.
Scan_Out_Enable is a module input that indicates to the module that scan data can now be output. Data is considered to be shifted out of the module whenever there is a rising edge of the core clock, this signal is asserted and the module is asserting Scan_Out_Ready. Scan_Out_Enable is connected to the Scan_In_Ready of the next module in the chain if it exists or to the logic that saves the scan data otherwise.
Scan_Out_Ready is a module output that indicates that the module is ready to output data. It is de-asserted while the module is in the process of discarding its state because Save is not asserted. When module state is not being discarded, Scan_Out_Ready is logically connected to Scan_In_Enable. Scan_Out_Ready is connected to the Scan_In_Enable of the next module in the chain if it exists or to the logic that saves the scan data otherwise.
Swap is a module input that is connected to the Swap inputs of all the scan cells in the module. When asserted during the rising edge of the core clock, the state of each active flip flop is exchanged with the state in the scan flip flop. This signal is connected to the logic that determines when to swap states.
Enable is a module input that controls processing within the module. When asserted, the module will perform its normal operation. When deasserted, the module will finish all currently active transactions with other modules and deassert all requests for new transactions, thus making it safe to save, swap, or restore state. The implementation of this within each module is module dependent. It is this signal that prevents multi clock cycle transactions from being interrupted and restarted out of context. The Enable signal of each module is connected to a separate bit in the master enable control register. Reset_Count is a module input that, when asserted on the rising edge of a core clock, resets the module""s shift count. This count is used to determine how many bits to discard when not saving and restoring the module""s state at the same time. Save is a module input that, when asserted, allows the module""s state to be saved. When this signal is not asserted, the module""s state is not included in the data shifted through the module. The Save signal of each module is connected to a separate bit in the multitasking control register.
Restore is a module input that, when asserted, allows the module""s state to be restored. When this signal is not asserted, data shifted into the module""s Scan_In signal is sent directly to the module""s Scan_Out instead of through the module""s scan chain. The Restore signal of each module is connected to a separate bit in the multitasking control register.
Under normal operation, which is defined as shifting data through the module, the module""s Scan_Out_Ready signal is logically connected to its Scan_In_Enable signal, its Scan_In_Ready signal is logically connected to its Scan_Out_Enable signal, and the Scan_Out signal is connected to the Scan_Output of the last Scan Cell in the module""s chain of Scan Cells. This allows data to be shifted through the module whenever both the data source and destination are ready. When a module""s state is either not being saved or not being restored, data is discarded or not loaded into the module by manipulating the Scan_Out_Ready and Scan_In_Ready signals and the source of Scan_Out data while shifting, as described below.
Although most of the time the module""s Scan_In is logically connected to first scan cell""s Scan_Input, this is not the case for when the module""s data is being discarded because it was not in use before the last swap. If a module was not in use before the last swap and will not be in use after the next swap, the application, i.e. the process controlling use of the module, must set the Save and Restore signals for the module inactive. This causes the output scan control signals to be logically connected to the input scan control signals to cause scan data to flow around the module.
If a module was not in use before the last swap and will not be in use after the next swap, the application must de-assert the Save and Restore signals while shifting state data. This causes the output scan control signals to be logically connected to the input scan control signals to cause scan data to flow around the module.
If a module was not in use before the last swap and will be in use after the next swap, the application must de-assert the Save signal and assert the Restore signal while shifting state data. This causes the module""s state to be discarded by de-asserting the Scan_Out_Ready signal and asserting the Scan_In_Ready signal until a module""s worth of data has been shifted in. After the state data has been discarded, normal shift operation is resumed.
If a module was being used before the last swap and will not be in use after the next swap, the application must assert the Save signal and de-assert the Restore signal while shifting state data. This causes the module""s state data to be saved without shifting in new state by asserting the Scan_Out_Ready signal and deasserting the Scan_In_Ready signal until a module""s worth of data has been shifted out. After the state data has been saved, normal shift control is resumed but Scan_Out data is taken directly from Scan_In to prevent data destined for other modules from being lost in the module.
If a module was being used before the last swap and will still be used after the next swap, the application must set the Save and Restore signals active. This configures normal module operation as described above and the existing state will be saved while a new state is shifted in.
To swap tasks, the application first deasserts the Eenable signals of all the modules. This causes them to stop processing data and, consequently, allows any state machines that are in the middle of multi-clock interactions with other modules to finish. Then, the application selects the modules to be saved and restored by programming the multitasking control register with an appropriate value. Then, by writing to a special register location, the Swap and ResetMultitaskCount signals are asserted for one clock cycle to cause the active data to be swapped with the data from the task to be restored and to reset the module bit counters. With the state of the task to be restored now in the part, the application starts the task processing by writing the appropriate bit pattern to the enable register. While the restored task is processing data, the state of the next operation to restore is then shifted into the Scan_In signal of the first module in the chain and the data to be saved from the task that was just interrupted is shifted out from the Scan_Out signal of the last module in the chain.
By shifting in data to be restored at the next state swap and shifting out data from the last swap at the same time, a save and a restore operation occur simultaneously. Although this is the most time efficient manner of swapping state, there may be times where the task to invoke at the next swap is not know when saving the state from the last swap. In this case, it is also possible to save the state from the last swap and then restore the state for the next swap. This is done by programming the multitasking control register to save the required state without restoring any state. After the state save has completed, the application restores the needed state by writing to a special register that causes the multitasking counters to be reset. It then configures the multitasking control register for the state restore and loads the data into the part.
Two methods of saving and restoring state data are provided. The application can perform a Direct Memory Access of data to or from a module or the module can use its dedicated SRAM for storage, such activities being controlled by registers in the module.
According to a first aspect of the present invention, a scan cell for storing state data associated with more than on task comprises a data memory device configured to hold state data and having a data input terminal, a data output terminal, and a control input terminal; a scan memory device configured to hold state data and having a scan input terminal, a scan output terminal, and the control input terminal; and control logic coupled to the data memory device and the scan memory device and configured to initiate swapping of the state data in the data memory device with the state data in the scan memory device upon a predetermined event.
According to a second aspect of the present invention, a scan chain comprises a plurality of scan cells, each scan cell having first and second memory devices capable of holding data and interconnected to allow swapping of data between the memory devices, the plurality of scan cells being serially interconnected to enable propagation of data sequentially through the first memory devices of the scan cells; the plurality of scan cells being serially interconnected to enable propagation of data sequentially through the second memory devices of the scan cells; and control logic configured to initiate swapping of the data between the first and second memory devices upon the occurrence of a predetermined event.
According to a third aspect of the present invention, a method for managing state data in a system having a scan chain, the scan chain being configured to hold state data associated with a module of the system, the scan chain comprising a plurality of scan cells, the scan cells comprising data memory device and scan memory devices, the method comprising: (A) receiving a swap signal at a control input terminal of the scan cells; (B) swapping, in response to the swap signal, state data in the data memory device of each scan cell with state data in the scan memory device of each scan cell; (C) saving the state data from the scan memory device a each scan cell to a storage source; and (D) loading new state data into the scan memory device of each scan cell.